First of all, @dmarkham, thank you for the wonderful library.
We are happily use it in our go project.

I will go straight to the case.

When the receiver does not support the new enum value, it accepts it formally.
Next, the string representation returns a formatted value, like "Day(451)".
I allowed myself to return an empty string in case of errors.
I understand that it reduces verbosity but i think it matches better the go principles.

The other thing is error handling. Some converters always return nil error despite of the fact that the value is incorrect.
I have took it into account and implemented it as follows:

func (i Day) string() (string, error) {
// the actual implementation
}

func (i Day) String() string {
	val, _ := i.string() // just Stringer, ignores error
	return val
}

func (i Day) MarshalYAML() (interface{}, error) {
	return i.string() // and here we use the actual implementation, that supports error return
}

As you can see, the superposition of error handing e.g. in SQL marshaller and formatting of unknown value can lead to funny behavior.
In our case, there was a bug in our code related to the 2 described edge-cases.
Now i present the PR to you hoping you find some time to look at it and tell your opinion.

Thank you for your attention!